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1 Introduction 

The locator/identifier spht approach as- 
sumes separating functions of a locator (i.e. 
topology-dependent attachment point ad- 
dress) and identifier (topology-independent 
unique identifier) currently both served by 
an IP address. This work is an attempt to 
redefine semantics of MAC address to make 
it a pure layer-2 locator instead of a pure 
globally-unique identifier. Such an exercise 
might be interesting from the standpoint of 
Ethernet scaling and Metro Ethernet tech- 
nologies. From the global routing perspec- 
tive, introduction of multihoming, traffic en- 
gineering and failover at the 2nd layer may 
reduce pressure on the 3rd layer. 

Historically, an Ethernet network was sup- 
posed to be a single wire with many de- 
vices attached. For reliable identification, 
each device has a factory-preset globally- 
unique 6-byte MAC address. Each Ether- 
net frame has destination and source MAC 
addresses. Currently, switched networks are 
prevalent, so one physical "wire" normally 
connects just two devices. Layer-2 switched 
networks are typically divided into fiat logical 
segments (VLANs) where MAC addresses are 
used as pure identifiers to perform frame for- 
warding/routing using spanning trees and an- 
nounce flooding. Interestingly, that behavior 
is more akin to what was traditionally con- 
sidered as "routing" , albeit ultimately it still 
emulates shared copper. 

The trick is to try to introduce advanced 
routing options and topologies to the data 
link layer of a given network, without touch- 
ing anything at the 3rd layer or end hosts. 



2 Redefining MAC 

The objective is to ease layer-2 switching in 
large layer-2 networks by overloading MAC 
addresses to be pure locators. IP address thus 
plays as a pure identifier. 

As a matter of fact, mesh networks are 
not effective. STP protocol, for example, 
starts with deactivating extra links to turn 
the topology into a tree. I will consider a 
tiered architecture where every switch is con- 
nected to some uplink switches and some 
downlink switches/devices. "Horizontally" 
connected switches are modeled as a single 
switch ("stacking"). Shortcutting, a weaker 
form of "horizontal" linking, is modeled 
fictive common uplink switch. 

The proposed addressing scheme is a 
feature-cut of the prefix-bunch architecture. 
A device of i-th tier has a number of "Big- 
MAC" addresses consisting of i meaningful 
bytes and 6—i padding zeroes: {bi. . .biO . . .}. 
More precisely, each such address belongs to 
some uplink port. Further, c-th downlink 
port is assigned addresses {bi. . .bi c . . .}. 

Thus, every BigMAC address corresponds 
to a downward path from some top-tier 
switch to the target device. Differently from 
hierarchical addressing, all the network's ad- 
dresses combined form not a tree, but a tree- 
resembling structure I will christen a "branch 
bunch" . The average number of addresses an 
end host will have is estimated as N^°<^2 d-iog2 « ^ 
where is the number of end hosts; u and d 
are uplink/downlink fanouts resp. (So, 
for w = 2, d = 32.) It is not generally sup- 
posed that a device knows all of its addresses. 
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3 Switching 



4 ARP&DHCP 



Obviously, forwarding a frame from uplink to 
downlink is as simple as checking {i + l)-th 
byte of the destination address which con- 
tains the number of the egress port. To for- 
ward a frame from a downlink up, a switch 
has to direct the frame to the uplink port 
that owns the source BigMAC address (strat- 
egy a). The switch might as well rewrite 
first i bytes of the source address to forward 
the frame to an arbitrary uplink - assuming, 
that the top-tier switches are fully intercon- 
nected (strategy (3). A more sophisticated 
upward-forwarding strategy is to check the 
destination address against available uplink 
addresses to detect the longest prefix match 
(strategy 7). Albeit, this functionality is not 
dirt-cheap to implement, so it is better to 
shift it away from the switch, see Sec. HI 

Another strategy 6 may reduce upward for- 
warding to the same kind of byte-check em- 
ployed by downward forwarding. Namely, if 
a typical switch has 24. . . 32 ports and uses 
a byte of addressing space, then there are 3 
spare bits to use. As the number of uplinks 
is supposedly less than 8, 3 bits of the byte 
may stand for the number of the uplink the 
original BigMAC came from, while the rest 
5 denote the downlink port, as before. So, 3 
bits of the (z-l-l)-th byte of the source address 
denote the egress uplink port. 

One more issue is when to forward from 
downlink to downlink. One criterion is first 
i bytes of the source address being equal to 
the first i bytes of the destination address. 

To preserve compatibility with the end 
hosts, some MAC address rewriting is needed. 
By using ARP, end hosts learn BigMACs of 
peers (see Sec. S]). To fully control host-to- 
host traffic paths, we have to set both source 
and destination BigMACs. So, a customer- 
edge switch has not only to rewrite genuine 
MAC of an end host for a BigMAC, but also 
to remember which particular source Big- 
MAC to use for a given destination BigMAC. 
By sacrificing one byte of BigMAC this is also 
reduced to a byte-check (left as an excercise). 



To remain backward compatible with Ether- 
net -|-IP end host stacks, a different function- 
ing of ARP and DHCP is needed. I suppose 
that all ARP and DHCP traffic is diverted to 
some dedicated ARP&DHCP server. Possi- 
ble variants of distributed/tiered implemen- 
tation are omitted. 

All ARP/DHCP broadcasts of end hosts 
are upward-flooded, i.e. sent to every up- 
link. Finally, ARP&DHCP server gets a copy 
of a request from every possible path, thus 
passively learning the topology. The total 
amount of requests is thus 0(A^^'^^) for the 
reference case of u = 2,d = 32. A reply trav- 
els by a single path to the end host. 

As mentioned, ARP server may do some 
traffic engineering by sending a reply contain- 
ing BigMAC of the target host to a particu- 
lar BigMAC address of the requesting host so 
the edge switch learns the association. This 
way we may "outsource" the aforementioned 
longest-prefix matches to a dedicated out-of- 
band entity and cache them later on (benefits 
of 7 for the price of 6). That also opens pos- 
sibilities for load balancing. 

Some failover and on-the-fiy reconfigura- 
tion functionality might be achieved by the 
means of ARP announcements. 

5 Conclusion 

So, if nothing important was overlooked, 
branch-bunch locators may bring many gains 
to the data link layer. Switching logic is 
dramatically simplified; it needs no routing 
tables, no associative memory lookups, no 
longest prefix matches. Scalability is high as 
forwarding-related computational load on a 
single switch generally does not depend on 
the size of the network. The network has sim- 
ple tools for basic traffic engineering: on-the- 
fiy load balancing and failover. Last but not 
least, the approach preserves backward com- 
patibility. Anyway, any questions, comments, 
criticisms and considerations are welcomed. 
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